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Abstract 

In  this  paper  we  describe  a  policy  language  designed 
for  pervasive  computing  applications  that  is  based  on  de- 
ontic  concepts  and  grounded  in  a  semantic  language.  The 
pervasive  computing  environments  under  consideration  are 
those  in  which  people  and  devices  are  mobile  and  use  var¬ 
ious  wireless  networking  technologies  to  discover  and  ac¬ 
cess  services  and  devices  in  their  vicinity.  Such  pervasive 
environments  lend  themselves  to  policy-based  security  due 
to  their  extremely  dynamic  nature.  Using  policies  allows 
the  security  functionality  to  be  modified  without  changing 
the  implementation  of  the  entities  involved.  However,  along 
with  being  extremely  dynamic  these  environments  also  tend 
to  span  several  domains  and  be  made  up  of  entities  of  var¬ 
ied  capabilities.  A  policy  language  for  environments  of  this 
sort  needs  to  be  very  expressive  but  lightweight  and  easily 
extensible.  We  demonstrate  the  feasibility  of  our  policy  lan¬ 
guage  in  pervasive  environments  through  a  prototype  used 
as  part  of  a  secure  pervasive  system. 


1.  Introduction 

Policies  guide  the  behavior  of  entities  within  the  policy 
domain  and  have  been  used  extensively  in  security,  man¬ 
agement  and  even  network  routing.  Policy -based  security 
is  often  used  in  systems  where  flexibility  is  required  as 
users,  services  and  access  rights  change  frequently.  As 
computationally  enabled  devices  (laptops,  phones,  PDAs, 
and  even  household  appliances)  become  more  common¬ 
place  and  short  range  wireless  connectivity  improves,  there 
is  a  increased  need  for  more  automated  security  in  the  re¬ 
sulting  pervasive  environments  formed  by  mobile  users  ac¬ 
cessing  these  resources  and  other  services  and  information 
using  handheld  devices.  These  environments  will  be  popu- 
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lated  by  a  large  number  of  wirelessly  networked  heteroge¬ 
neous  users,  services  and  semi- automated  entities  of  varied 
capabilities  making  it  necessary  to  ensure  that  all  these  dif¬ 
ferent  entities  behave  appropriately.  Towards  this  end,  we 
believe  that  policy  based  security  will  be  the  most  effective 
as  it  will  be  possible  to  modify  how  different  entities  act 
without  modifying  their  internal  mechanism. 

Policies  generally  require  application  specific  informa¬ 
tion  to  reason  over,  forcing  researchers  to  create  policy  lan¬ 
guages  that  are  bound  to  the  domains  for  which  they  were 
developed.  This  prevents  policy  languages  from  being  flex¬ 
ible  or  being  applicable  across  domains.  In  order  to  enable 
entities  in  pervasive  computing  systems,  which  consist  of 
different  domains  and  systems,  to  understand  and  interpret 
policies  correctly,  we  propose  that  they  be  represented  in 
a  semantic  language  like  RDF-S  [4],  DAML+OIL  [8]  or 
OWL  [6].  We  believe  that  using  a  semantic  language  al¬ 
lows  different  systems  to  share  a  model  of  policies,  roles 
and  other  attributes  [3,  12]. 

In  this  paper,  we  describe  the  specification  of  our  pol¬ 
icy  language,  Rei1.  Rei  is  based  on  deontic  concepts 
[17,  18,  27]  and  includes  constructs  for  rights,  prohibitions, 
obligations  and  dispensations  (deferred  obligations).  The 
language  consists  of  a  few  simple  constructs  that  are  ex¬ 
tremely  flexible  and  allows  different  kinds  of  policies  (se¬ 
curity,  privacy,  management,  conversation  etc.)  to  be  spec¬ 
ified.  The  policy  language  is  not  tied  to  any  specific  appli¬ 
cation  and  permits  domain  specific  information  to  be  added 
without  modification.  As  our  policy  language  is  geared  to¬ 
wards  environments  that  consist  of  several  domains  we  be¬ 
lieve  that  there  is  a  potential  for  policy  conflicts.  The  lan¬ 
guage  includes  two  constructs  for  specifying  meta-policies 
that  are  invoked  to  resolve  conflicts;  setting  the  modality 
preference  (negative  over  positive  or  vice  versa)  or  stating 


^ei,  pronounced  ray,  is  a  Japanese  ’Kanji’  character  which  means 
’universal’  or  ’essence’.  It  was  chosen  to  indicate  the  universal  applica¬ 
bility  of  the  policy  language,  as  its  flexibility  and  versatility  allow  a  large 
variety  of  policies,  including  security,  conversation  and  management,  to  be 
specified. 
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the  priority  between  policies.  For  example,  it  is  possible  to 
say  that  in  case  of  conflict  the  Federal  policy  always  over¬ 
rides  the  State  policy. 

In  pervasive  environments,  describing  comprehensive 
policies  may  be  time  consuming,  if  at  all  possible.  We  be¬ 
lieve  that  policies  should  be  as  simple  as  possible  and  con¬ 
trol  should  be  decentralized,  that  is  authorization  should  be 
possible  by  more  than  just  a  few  key  entities.  Rei  models 
speech  acts  like  delegation,  revocation,  request  and  cancel 
that  allow  policies  to  be  less  exhaustive  and  allow  for  de¬ 
centralized  security  control. 

Due  to  the  large  number  of  entities  in  the  environment, 
it  may  not  be  possible  to  identify  them  accurately  or  even 
pre-determine  the  users  of  each  service.  Therefore  we  sug¬ 
gest  developing  policies  associated  with  properties  of  enti¬ 
ties  instead  of  identities  [11,13].  These  properties  are  estab¬ 
lished  by  proving  them  from  an  entity’s  credentials,  beliefs 
of  other  entities  and  the  appropriate  security  policies. 

The  paper  is  structured  as  follows:  The  discussion  about 
the  specification  of  the  language  in  Section  2  includes  the 
policy  constructs,  the  action  specifications  and  the  repre¬ 
sentation  of  domain  specific  information.  Following  this,  in 
Section  3  we  describe  the  types  of  possible  conflicts  and  the 
meta  policies  that  can  be  used  to  resolve  them.  As  delega¬ 
tion  management  is  very  important  in  the  environments  we 
work  with,  in  Section  4  we  present  our  approach  to  dele¬ 
gation  and  discuss  the  types  of  delegation  Rei  covers.  The 
implementation  details  of  the  policy  engine  associated  with 
Rei  are  covered  in  Section  5.  In  Section  6  we  talk  about  a 
prototype  of  a  secure  pervasive  system  that  we  developed  to 
test  the  feasibility  of  the  policy  language.  After  discussing 
related  background  work,  we  state  the  contributions  of  our 
research  in  Section  8.  Finally  in  Section  9  we  summarize 
our  work  and  describe  future  research  directions. 

2.  Structure  of  Policy  Language 

Our  policy  language  is  modeled  on  deontic  concepts  of 
rights,  prohibitions,  obligations  and  dispensations  [10].  We 
believe  that  most  policies  can  be  expressed  as  what  an  entity 
(user,  agent,  service,  etc.)  can/cannot  and  should/should  not 
do  in  terms  of  actions,  services,  conversations  etc.,  making 
our  language  capable  of  describing  a  large  variety  of  poli¬ 
cies  ranging  from  security  policies  to  conversation  and  be¬ 
havior  policies.  Rei  is  implemented  in  a  logic  language, 
namely  Prolog  [24].  We  have  also  developed  ontologies 
that  enables  the  policy  engine  to  interpret  a  subset  of  RDF-S 
policies. 

The  Rei  policy  language  includes  certain  domain  inde¬ 
pendent  ontologies  and  accepts  domain  dependent  ontolo¬ 
gies.  The  former  includes  concepts  for  permissions,  obli¬ 
gations,  actions,  speech  acts,  operators  etc.  The  latter  is  a 
set  of  ontologies,  shared  by  the  entities  in  the  system,  which 


define  domain  classes  (person,  file,  deleteAFile,  readBook) 
and  properties  associated  with  the  classes  (age,  num-pages, 
email). 

Though  the  execution  of  actions  is  outside  the  policy  en¬ 
gine,  the  policy  language  includes  a  representation  of  ac¬ 
tions  that  allows  more  contextual  information  to  be  captured 
and  allows  for  greater  understanding  of  the  action  and  its 
parameters.  It  similarly  permits  domain  dependent  infor¬ 
mation  to  be  added. 

Rei  includes  three  types  of  constructs:  (i)  policy  objects, 
(ii)  meta  policies  and  (iii)speech  acts,  (i)  The  policy  ob¬ 
jects  represent  rights,  obligations,  prohibitions  and  dispen¬ 
sations.  The  has  policy  construct  allows  these  objects  to 
be  associated  with  different  entities  creating  policy  rules. 
This  allows  for  reuse  of  policy  objects.  For  example,  the 
same  right  to  read  a  certain  file  could  be  associated  with 
different  entities  in  different  policy  domains,  (ii)  The  pol¬ 
icy  language  contains  meta-policy  specifications  for  conflict 
resolution.  These  include  constructs  for  specifying  prece¬ 
dence  of  modality  and  priority  of  policies,  (iii)  Rei  models 
four  speech  acts  that  can  be  used  within  the  system  to  mod¬ 
ify  policies  dynamically:  delegate,  revoke,  cancel  and  re¬ 
quest.  In  order  to  make  correct  policy  decisions,  we  assume 
the  presence  of  a  monitoring  service  that  sends  all  relevant 
speech  acts  to  the  policy  engine.  Associated  with  the  pol¬ 
icy  language  is  the  policy  engine  that  interprets  and  reasons 
over  the  policies,  speech  acts  and  domain  information  to 
make  decisions  about  users  rights  and  obligations. 

2.1.  Policy  Objects 

The  core  of  the  policy  language  is  the  set  of  constructs 
that  describe  the  concepts  of  rights,  prohibitions,  obliga¬ 
tions,  and  dispensations.  These  constructs  denoted  by  Poli- 
cyObject  are  represented  as 

-  Policy Object( Action,  Conditions ) 

where,  Action  is  a  domain  dependent  action  and  Condi¬ 
tions  are  constraints  on  the  actor,  action  and  environment. 
A  policy  object  defines  a  commonly  occurring  right,  obli¬ 
gation,  prohibition  and  dispensation.  For  example,  the  right 
to  print  to  a  certain  printer,  the  obligation  to  brew  a  fresh 
pot  of  coffee  when  the  coffee  pot  is  empty,  etc. 

In  order  to  associate  a  policy  object  with  an  entity,  the 
has  construct  is  used. 

-  has(Subject,  Policy  Object) 

where,  Subject  can  either  be  a  URI  identifying  an  entity 
or  a  variable,  allowing  all  entities  who  satisfy  the  conditions 
to  be  associated  with  the  policy  object  to  possess  the  policy 
object.  A  policy  consists  of  several  has  rules. 

Rei  allows  role  based  or  group  based  policies  to  be 
defined  by  using  has  with  a  variable  and  specifying  the 
role  or  group,  which  are  domain  dependent,  as  part  of  the 
condition  of  the  policy  object.  In  this  way,  policies  can 


be  individual,  role,  group  -  based,  or  any  combination  of 
the  three.  This  mechanism  is  different  from  existing  policy 
languages,  which  include  special  constructs  for  role/group 
based  rights/obligations  [5,  15]. 

There  are  four  kinds  of  policy  objects:  (i)  Rights,  (ii) 
Prohibitions,  (iii)  Obligations,  and  (iv)  Dispensations. 

•  Rights  are  permissions  that  an  entity  has.  The  posses¬ 
sion  of  a  right  allows  the  entity  to  perform  the  associ¬ 
ated  action. 

An  entity,  abc ,  can  perform  an  action,  actionABC  if 
and  only  if  at  least  one  of  the  following  conditions  are 
true 

-  has(abc,  right( actionABC,  Conditions ))  and  abc 
satisfies  Conditions 

-  has  (Variable2,  right(  actionABC,  Conditions )), 
abc  binds  to  Variable  and  satisfies  Conditions 


Example  1.  A  rule  that  states  that  all  employees  of 
’UMBC’  can  perform  print  Action  1  is  represented  as 

has(Variable,  ri ght(print Action 1 ,  ( employ ee( Variable, 
’UMBC')))) 

In  this  policy  rule,  printActionl  is  an  action  and  em¬ 
ployee  is  a  condition. 

•  Prohibitions  are  negative  authorizations  implying  that 
an  entity  cannot  perform  the  action. 

An  entity,  abc ,  is  prohibited  from  performing  action¬ 
ABC  if  and  only  if  at  least  one  of  the  following  condi¬ 
tions  is  true 

-  has(abc,  prohibition( actionABC,  Conditions )) 
and  abc  satisfies  Conditions 

-  has(Variable,  prohibition( actionABC,  Condi¬ 
tions ))  and  abc  satisfies  Conditions 

Example  2.  A  rule  that  states  that  students  of  ’ UMBC ’ 
are  prohibited  from  using  the  faculty  printer  is  speci¬ 
fied  as 

has(Variable,  prohibition(useFacultyPrinter,  (stu¬ 
dent  Variable,  ’  UMBC’) ))) 

use  Faculty  Printer  is  an  action  and  student(Variable, 

’ UMBC ’)  is  a  condition  that  an  entity  must  satisfy  in 
order  to  possess  the  prohibition. 

2In  prolog,  any  word  starting  with  an  uppercase  letter  is  assumed  to  be 
a  variable.  All  constants  start  with  a  lowercase  letter. 


•  Obligations  are  actions  that  an  entity  must  perform  and 
are  usually  triggered  when  a  certain  set  of  conditions 
are  true. 

An  entity,  abc ,  is  obliged  to  perform  actionABC  if  and 
only  if  one  of  the  following  conditions  are  true 

-  has(abc,  obligation( actionABC,  Conditions )) 
and  abc  satisfies  Conditions 

-  has(Variable,  obligation( actionABC,  Condi¬ 

tions ))  and  abc  satisfies  Conditions 

Example  3.  A  policy  rule  specifying  that  all  employees 
of  ’ABC’  should  display  their  badges  while  at  work  is 
represented  as 

has(Variable,  obliged(  display  Badge,  ( em¬ 

ploy  ee(X; ABC),  atWork(X)))) 

displayBadge  is  an  action  and  employee(X,  ’ABC’  and 
atWork(X)  are  a  domain  dependent  condition. 

There  are  additional  parameters  associated  with  Obli¬ 
gation  for  better  processing  of  the  policy  object;  Met- 
Effects  and  NotMetEffects  [20].  The  subject  can  de¬ 
cide  whether  to  complete  the  obligation  by  comparing 
the  effects  of  meeting  the  obligation  (MetEffects)  and 
the  effects  of  not  meeting  the  obligation  (NotMetEf¬ 
fects).  However,  this  reasoning  is  not  part  of  the  policy 
engine  and  is  left  to  the  individual  subject.  The  pol¬ 
icy  engine  learns  of  the  environment  including  actions 
being  performed,  relevant  speech  acts,  and  other  con¬ 
textual  information  from  the  monitoring  service.  Us¬ 
ing  this  information,  the  policy  engine  is  able  to  infer 
which  obligations  were  fulfilled  and  which  obligations 
still  need  to  be  fulfilled. 

•  Dispensations  are  actions  that  an  entity  is  no  longer 
required  to  perform.  They  act  as  waivers  for  existing 
obligations. 

An  entity,  abc ,  is  no  longer  obliged  to  perform  an  ac¬ 
tion,  actionABC  if  and  only  if 

-  has(abc,  obligation(actionABC,  OConditions)) 
and  if  abc  satisfies  OConditions 

-  has(abc,  dispensation  actionABC,  DCondi- 

tions))  and  if  abc  satisfies  DConditions. 

OR 

-  has(Variable,  obligation  actionABC,  OCondi¬ 
tions ))  and  if  abc  satisfies  OConditions 

-  has(Variable,  dispensation  actionABC,  DCondi¬ 
tions ))  and  if  abc  satisfies  DConditions. 

Example  4.  John  is  no  longer  required  to  pay  alimony 
to  his  wife  after  she  re-marries. 

has(john,  dispensation^ ay Alimony,  wife(john,  X),  re- 
married(X))) 


2.2.  Action  Specifications 

The  policy  language  suggests  a  representation  of  actions 
that  allows  for  greater  understanding  of  the  action  and  its 
parameters.  Actions  can  be  represented  as  a  tuple  with  the 
following  parameters 

-  action(ActionName,  TargetObjects,  Pre-Conditions, 
Effects) 

where,  ActionName  is  the  identifier  or  URI  of  the  action, 
TargetObjects  is  a  list  of  objects  on  which  the  action  is 
performed,  Pre-Conditions  are  the  conditions  that  need  to 
be  true  before  the  action  can  be  performed  and  Effects  are 
the  results  of  the  action  being  performed.  Preconditions 
reflect  the  context  in  which  the  action  can  be  performed 
and  Effects  are  used  to  infer  the  state  of  the  environment 
after  the  action  is  performed. 

Example  5.  The  action  of  printing  a  page  on  printerHP 
can  be  represented  as 

action(printOnePageHP,  [printerHP],  (containsCar- 
tridge(printerHP),availablePaper(printerHP,  X),  X  >  1), 
availablePaper (printerHP,  X-l )) 

2.2.1.  Action  Operators 

Though  we  would  like  the  policy  language  to  be  as  sim¬ 
ple  as  possible,  certain  additional  constructs  are  required  to 
create  complex  action  descriptions.  For  example,  there  is  a 
difference  between  John  having  the  permission  to  perform 
action  A  followed  by  B,  and  John  having  the  permission 
to  perform  A  and  the  permission  to  perform  B.  We  tried  to 
model  these  operators  using  the  existing  action  specifica¬ 
tions  but  were  unable  to  come  up  with  a  satisfactory  result 
forcing  the  additional  complexity. 

The  policy  language  includes  four  action  operators  that 
allow  various  kinds  of  complex  actions  to  be  specified;  se¬ 
quence,  non-deterministic,  once,  and  repetition  [7]. 

•  Sequence  :  If  A  and  B  are  actions,  seq(A,B)  denotes 
that  action  B  must  only  be  performed  after  action  A  or 
that  action  A  and  B  must  be  performed  in  sequence. 

•  Non-deterministic  :  If  A  and  B  are  actions,  nond(A,B) 
denotes  a  choice  between  A  and  B  implying  either  A 
or  B  can  be  performed,  but  not  both. 

•  Repetition  :  If  A  is  an  action,  repetition(A )  denotes  that 
A  can  be  executed  several  times. 

•  Once  :  If  A  is  an  action,  once(A)  denotes  that  A  can 
only  be  performed  once. 

Example  6.  Consider  a  right  associated  with  John.  John 
has  the  right  to  either  perform  action  printBW  followed  by 
repeated  executions  of  printColor  or  perform  action  faxBW 


once.  He  only  has  the  right  while  he  is  a  lab  member  of 
’AT. 

has(john,  right(nond(  seq(  printBW,  repeti- 
tion(printColor)),  once(faxBW)),  lab-member(john,AE ))). 

2.3.  Speech  Acts 

As  Rei  is  geared  towards  highly  distributed  and  large  en¬ 
vironments,  it  includes  a  representation  of  speech  acts  that 
are  used  to  decentralize  control.  The  policy  language  cur¬ 
rently  includes  specifications  for  four  speech  acts  that  affect 
the  policy  objects  of  the  communicating  entities:  (i)  delega¬ 
tion,  (ii)  request,  (iii)  cancel,  and  (iv)  revocation.  These 
speech  acts  are  also  governed  by  policies  and  entities  can 
only  use  a  certain  speech  act  if  they  have  the  right  to  it. 
Consider  for  example,  John  may  have  the  right  to  send  a  re¬ 
quest  to  Joan  but  not  a  delegate  or  a  cancel.  The  structure 
of  the  speech  acts  allows  for  natural  nesting  of  speech  acts 
with  policy  objects.  For  example,  it  is  possible  to  request 
a  dispensation  or  cancel  a  request.  The  policy  engine  cur¬ 
rently  implements  a  certain  subset  of  these  nested  speech 
acts  namely  delegation  of  rights  and  actions,  requesting  of 
rights  and  actions,  cancellation  of  requests,  and  revoking  of 
any  types  of  rights  including  the  right  to  delegate. 

•  Delegation  :  A  delegation  allows  an  entity  to  give  a 
right  to  another  entity  or  group  of  entities.  A  delega¬ 
tion,  if  valid,  causes  a  Right  to  be  created.  Only  an 
entity  with  the  Right  to  delegate  can  make  a  valid  del¬ 
egation.  A  delegator  always  retains  the  right  to  revoke 
the  delegated  right. 

A  delegation  can  be  represented  as 

-  delegateSpeechAct( Sender,  Receiver,  right(Action, 
Condition ))  and  Receiver  satisfies  Conditions  — > 
has( Receiver,  right(Action,  Condition ) ) 

Example  7.  Assuming  that  John  has  the  right  to  dele¬ 
gate,  he  delegates  to  Mark  the  right  to  print  on  the  lab 
printer  as  long  as  he  is  working  on  the  same  project  as 
John. 

delegateSpeechAct(john,  mark, 

right( printLabPrinter,  ( project(john,  SomeProject), 

project(mark,  SomeProject)))) 

action( printLabprinter,  [laserPrinterl23  ], 

queue(  laserPrinterl  23,0),  queue(  laserPrinterl  23, 

1 )) 

•  Request  :  There  are  two  kinds  of  requests;  a  request 
for  an  action  and  a  request  for  a  right.  The  former,  if 
accepted,  causes  an  obligation  on  the  part  of  the  re¬ 
ceiver.  A  request  for  a  right,  if  valid  and  accepted, 
causes  the  receiver  to  delegate  the  right  to  the  sender. 


Figure  1.  Rei  Policy  Language  Ontology 


However,  the  delegation  allows  the  sender  the  permis¬ 
sion  to  perform  the  action  only  if  the  receiver  has  the 
right  to  delegate. 

-  requestSpeechAct( Sender,  Receiver,  Action)  — > 
disagree 

requestSpeechAct( Sender,  Receiver,  Action )  — > 
has( Receiver,  obligation(Action,  Condition )) 

-  requestSpeechAct( Sender,  Receiver,  right( Action, 
Condition ))  — >  disagree 

re quest( Sender,  Receiver,  right(Action,  Condi¬ 
tion ))  — > 

delegateSpeechAct( Receiver,  Sender, 
right(Action,  XCondition ) ) 

•  Revoke  :  Revocation  is  the  removal  of  a  right  and  acts 
as  a  prohibition.  A  revocation  is  allowed  in  two  cases; 
an  entity  can  revoke  those  rights  to  which  it  has  the 
right  to  revoke  or  those  rights  that  it  has  itself  dele¬ 
gated. 

revokeSpeechAct( Sender,  Receiver,  right(Action,  Con¬ 
dition))  — >  revocation( Receiver,  right(Action,  Condi¬ 
tion))  and  Sender  no  longer  has  the  right  to  perform 
Action 

•  Cancel  :  An  entity  can  cancel  any  request  it  has  sent, 
and  this  nullifies  any  obligation  or  delegation  caused 
by  the  request. 

-  cancelSpeechAct( Sender,  Receiver,  Action)  AND 
has( Receiver,  obligation(Action,  true))  — > 
has( Receiver,  dispensation(Action,  Condition )) 

-  cancelSpeechAct( Sender,  Receiver,  right( Action, 
X ))  — >  Sender  no  longer  has  the  right  to  per¬ 
form  Action 


2.4.  Domain  Specific  Information 

The  Rei  policy  engine  accepts  information  about  enti¬ 
ties  and  their  properties  in  any  semantic  language  that  can 
be  converted  into  triples  of  the  form  Subject,  Predicate,  Ob¬ 
ject).  It  understands  class  hierarchies  and  interprets  any  cor¬ 
rect  instance  of  our  ontology  or  any  subclasses.  All  seman¬ 
tic  information  is  stored  and  reasoned  over  in  triples.  Fig¬ 
ure  1  illustrates  the  ontology  we  are  developing  to  express 
policies  in  RDF-S  [4].  The  RDF-S  ontology  is  available 
at  http://daml.umbc.edu/ontologies/policy/dLnd  is  being  de¬ 
veloped  as  a  part  of  a  larger  ontology  of  security,  trust  and 
privacy  concepts.  As  an  example,  consider  a  security  pol¬ 
icy  being  developed  for  a  database  application.  Database 
related  actions  like  creating/viewing/deleting/updating  a  ta¬ 
ble,  adding/deleting/modifying  a  record,  and  creating  dif¬ 
ferent  views  will  be  instances  or  subclasses  of  our  Domain 
Action.  The  databases,  tables,  and  users  of  the  system  will 
be  represented  as  classes  under  Entity.  The  policy  itself  will 
be  specified  as  a  set  of  both  policy  rules  and  meta-policy 
rules. 

2.5.  Conditions 

As  it  is  not  always  possible  to  identify  entities  in  perva¬ 
sive  systems,  along  with  allowing  identity  based  policies, 
Rei  also  permits  policies  to  be  based  on  properties  of  the 
action,  targets,  subjects  and  other  environmental  factors  like 
time  and  place.  The  policy  languages  permits  complex  con¬ 
ditions  to  be  built  from  these  properties  and  supports  the 
following  operators; 

•  AND  :  A  complex  condition  made  of  two  conditions 
associated  with  an  AND,  will  be  true  only  when  both 
conditions  are  true. 


For  example,  (employee(X,  ’UMBC’),  lab-member(X, 
’AI’))  will  only  be  true  if  both  conditions  are  true 

•  OR  :  A  complex  condition  made  of  two  conditions  as¬ 
sociated  with  an  OR,  will  be  true  only  when  one  of  the 
conditions  is  true 

•  NOT  :  A  complex  condition  consisting  of 
not(ComplexCondition)  is  true  when  Complex- 
Condition  is  cannot  be  proved. 

Example  8.  As  an  example,  consider  a  complex  con¬ 
straint  made  of  application  dependent  conditions,  which  is 
when  the  agent  is  a  lab  member  of  ’AT  or  if  the  agent  is  not 
a  group  member  of  TR’ . 

(lab -member (X,  AI’);  not( group -member(X,  ’IR’))) 

However,  Rei  requires  a  semantic  rule  language  that  in¬ 
cludes  the  unification  of  variables  as  provided  by  Prolog. 
After  studying  the  existing  semantic  languages  like  RDF-S, 
DAML+OIL,  OWL  and  rule  based  languages  like  RuleML 
[2],  we  found  that  this  is  currently  not  supported.  We  are 
currently  looking  into  the  feasibility  of  using  a  language 
which  is  a  combination  of  Prolog  and  a  semantic  language 
to  represent  conditions.  Our  prolog  engine  currently  accepts 
conditions  as  combinations  of  triples  and  prolog  predicates. 

3.  Conflicts  and  Conflict  Resolution 

Due  to  the  nature  of  a  pervasive  environment,  we  expect 
that  there  will  be  several  policies  applicable  to  every  do¬ 
main  which  could  lead  to  potential  conflicts.  For  example, 
in  one  policy  Mary  has  the  obligation  to  write  the  report 
and  another  policy  prohibits  Mary  from  writing  the  same 
report.  Conflicts  occur  if  policies  overlap  in  subject,  target 
and  action  but  the  policy  objects  are  different. 

Based  on  Moffett  and  Sloman  [19]  we  identify  two  kinds 
of  conflicts 

•  Conflict  of  modality  :  These  conflicts  occur  when 
an  entity  is  authorized  to  perform  (Right)  and  forbid¬ 
den  from  performing  (Prohibition)  a  certain  action  on  a 
certain  set  of  targets  or  is  both  required  to  (Obligation) 
and  waived  from  (Dispensation)  performing  a  certain 
action  on  a  certain  set  of  targets.  This  includes  Rights, 
Prohibitions,  Obligations  and  Dispensations  caused  by 
speech  acts. 

•  Conflict  of  Obligation  and  Prohibition  :  These  con¬ 
flicts  occur  when  an  entity  is  required  to  perform  (Obli¬ 
gation)  and  forbidden  from  performing  (Prohibition)  a 
certain  action  on  a  certain  set  of  targets.  However,  in 
Rei  an  entity  must  have  the  right  to  perform  an  action 


before  performing  it,  which  causes  the  conflict  to  re¬ 
duce  to  a  conflict  between  a  Prohibition  and  a  Right. 

In  order  to  resolve  conflicts,  Rei  includes  meta-policies 
that  are  policies  about  how  policies  themselves  are  inter¬ 
preted  and  how  conflicts  are  resolved  at  run-time.  While 
reasoning  over  a  security  decision,  if  the  policy  engine 
comes  across  two  opposing  policy  objects  for  the  entities 
under  consideration,  it  declares  a  conflict  and  tries  to  find 
the  most  appropriate  meta  policy  to  resolve  the  conflict. 
Meta  policies  in  our  system  regulate  conflicting  policies  in 
two  ways;  (i)  priorities  and  (ii)  precedence  relations  [16]. 

3.1.  Priorities 

Priorities  can  be  specified  between  named  policy  rules  or 
even  entire  policies.  For  example,  it  is  possible  to  state  that 
the  school  policy  overrides  the  department  policy  in  case 
of  conflict.  It  is  also  possible  to  set  priorities  between  any 
two  rules.  If  there  is  a  rule,  AI,  giving  Mark  the  right  to 
print  and  a  rule,  Bl,  prohibiting  Mark  from  printing.  By 
using  overrides(Al,  Bl),  AI  is  given  priority  over  Bl.  The 
conflict  between  the  two  rules  is  resolved  at  run-time  giving 
Mark  the  right  to  print.  The  same  construct  is  used  to  spec¬ 
ify  priorities  between  policies.  It  is  also  possible  to  specify 
whether  priorities  between  policies  should  be  evaluated  be¬ 
fore  or  after  priorities  between  conflicting  policy  rules. 

3.2.  Precedence 

It  is  possible  to  specify  which  modality  holds  precedence 
over  the  other  in  the  meta-policies.  The  policy  maker  can 
associate  a  certain  precedence  for  a  set  of  actions  or  a  set 
of  entities  satisfying  certain  conditions.  The  constructs  to 
be  used  are  metaRule Action,  metaRuleAgent  and  metaRule. 
If  negative  modality  holds,  prohibitions  hold  over  rights 
and  dispensations  are  stronger  than  obligations  for  the 
set  of  entities  that  fulfill  the  associated  conditions  of  the 
meta-policy  construct,  for  positive  modality  it  is  the  reverse. 

The  three  kinds  of  meta  rules: 

•  metaRuleAction(ActionConditions,  positive/negative) : 
This  allows  the  modality  precedence  to  be  set  for  a  set 
of  actions  that  satisfy  the  action  conditions. 

•  metaRuleAgent(ConditionOnAgent,  positive/negative) 
:  This  allows  the  modality  precedence  to  be  set  for  a 
set  of  entities  that  satisfy  the  conditions. 

•  metaRule( Policy,  positive/negative)  :  This  is  the 
default  precedence  that  can  be  set  for  a  policy. 


Example  9.  A  meta  policy  that  specifies  that  for  any 
conflict  regarding  policies  for  employees  of  ABC,  negative 
modality  holds  precedence  is  defined  as 

metaRuleAgent( employ ee(X,  ’ABC’),  negative-modality ) 

There  exists  a  partial  ordering  among  the  meta-policies 
as  well  and  this  ordering  can  be  manipulated  for  every 
policy.  The  default  ordering  is:  the  meta  rules  associated 
with  actions  have  the  highest  priority,  followed  by  meta 
rules  about  subjects  and  if  there  are  no  rules  associated 
with  the  action  or  the  subject,  then  the  default  meta  rule  is 
considered. 


4.  Delegation  Management 

Delegation  is  important  in  highly  dynamic  and  widely 
distributed  systems  because  it  allows  the  policy  to  be  rela¬ 
tively  simple  and  allows  the  rights  of  entities  to  be  config¬ 
ured  dynamically.  A  policy  for  all  printers  in  a  lab  could  be 
defined  so  that  managers  have  the  right  to  delegate  the  right 
to  print  and  the  right  to  re-delegate  this  right  to  any  em¬ 
ployee  of  the  company.  However,  if  any  employee  that  they 
delegate  to,  misbehaves  in  any  way,  the  system  will  hold  the 
associated  manager  responsible.  This  forces  the  managers 
to  be  careful  with  their  delegations,  while  at  the  same  time 
allowing  the  rights  on  the  printers  to  propagate. 

The  Rei  policy  language  defines  three  types  of  inter¬ 
related  rights  associated  with  each  action,  out  of  which  the 
last  two  give  certain  delegation  rights. 

•  Right  to  execute  :  Possessing  this  right  allows  the 
agent  to  perform  the  action. 

has( Agent,  right( Action,  Condition )) 

where  Action  is  the  action  and  Condition  are  the  con¬ 
ditions  on  execution 

•  Right  to  delegate  execution  :  If  an  agent  possesses  the 
right  to  delegate  the  execution  of  an  action,  it  can  dele¬ 
gate  to  other  entities  the  right  to  perform  the  action  but 
the  agent  cannot  perform  the  action  itself. 

NOT  has( Agent,  right( Action,  ECondition)) 
has( Agent,  right(Actionl,  Conditionl)) 
where,  Conditionl  are  the  conditions  on  the  Agent 
Action  1  is  delegate(right( Action,  Condition )) 

This  right  gives  the  possessor  the  right  to  delegate  the 
previous  right,  the  right  to  execute. 

•  Right  to  delegate  delegation  right :  The  agent  can  del¬ 
egate  to  another  agent  or  a  group  of  entities  the  right 
to  further  delegate  the  right  to  perform  the  action  and 
delegate  this  delegation  right  as  well.  Though  at  this 


point  the  right  should  have  been  divided  into  right  to 
delegate  the  right  to  execution  and  the  right  to  delegate 
the  right  to  delegation,  we  decided  to  combine  them  as 
we  expect  that  the  conditions  on  every  right  will  take 
care  of  the  propagation  of  the  delegation.  This  right 
gives  the  possessor  the  right  to  delegate  the  previous 
right,  the  right  to  delegate  execution  and  the  right  to 
delegate  the  delegation  itself. 

NOT  has( Agent,  right(Action,  ECondition )) 
has( Agent,  right(Actionl ,  Conditionl )) 

where,  Conditionl  are  the  conditions  on  the  delegator, 
Agent 

Actionl  is  delegate(right(Action2,  Condition 2)) 
Condition2  are  the  conditions  on  the  delegatee 
Action  2  is  delegate(right( Action,  Condition )) 

These  three  rights  force  conditions  on  the  executor  of 
the  action,  the  delegator  of  the  action  and  whom  the  right 
can  be  delegated  to.  An  agent  has  the  right  to  a  certain 
action  (including  speech  acts)  if  it  possesses  the  right  or 
if  it  has  been  delegated  the  right.  It  should  satisfy  the 
conditions  associated  with  the  innermost  right  of  execution 
of  every  delegation  in  the  chain.  Each  delegator  should 
satisfy  the  condition  on  the  delegation  of  the  delegation 
before  it  in  the  chain  and  the  delegatee  conditions  of  all 
previous  delegations.  If  any  entity  fails  any  delegator 
condition,  the  delegations  from  that  point  on  are  invalid. 
The  policy  engine  ensures  that  circular  delegations  are  not 
allowed,  i.e.,  an  entity  cannot  delegate  a  right  to  itself  or  to 
another  entity  who  delegates  it  back  to  the  delegator  or  to  a 
previous  delegator  in  the  delegation  chain. 

Example  10.  This  example  demonstrates  the  working  of 
cascaded  delegations. 

•  Amy  has  the  right  to  delegate  the  right  to  execute 
printOnePageHP  and  she  delegates  this  right  to  Tim. 
Tim  can  only  execute  printOnePageHP  if  he  satis¬ 
fies  both  the  condition  associated  with  the  speech  act 
(employ ee(tim,  ’UMBC’)  and  the  condition  associ¬ 
ated  with  Amy’s  delegation  right  (group-member(X, 
Group)). 

has(amy,  right(amy,  delegate(right(X,  print,  group- 
member  (X, Group))),  employ ee(amy,  ’UMBC’))) 
delegateSpeechAct(amy,  tim,  right(tim,  print,  em¬ 
ploy  ee(tim,  ’UMBC’))) 

•  John  has  the  right  to  delegate  the  right  to  delegate 
the  right  to  execute  printOnePageHP  and  he  delegates 
this  right  to  Tim.  Tim  can  delegate  as  long  as  he  is 
satisfies  group-member(X,  Group)  from  John’s  right 
to  delegate  and  employ ee(tim,  ’UMBC’)  from  the 


delegation.  However,  John’s  right  and  the  delegation 
also  place  conditions  on  whom  Tim  can  delegate  to, 
in  this  case  to  lab  members  of  ’AI’  and  employees  of 
’UMBC’. 

has(amy,  right(john,  delegate(right(X,  dele- 
gate(right(Y,  print,  lab -member  (Y,  ’AI’))),  group- 

member(X,  Group ))),  employ  ee(john,’ UMBC’) )  ) 
delegateSpeechAct(john,  tim,  right(  tim, 

delegate(right(Y,  delegate(right(Z,  print, 

employ  ee(Z,’ UMBC ’))),  employee(Y, 

’ UMBC’) ) ), employ ee( tim,  ’ UMBC ’))) 

•  Tim  delegates  to  Jane  the  right  to  delegate  the  right 

to  execute  printOnePageHP.  Jane  must  satisfy  the 
conditions  associated  with  the  earlier  delegations 
and  rights  in  the  delegation  chain  in  order  to  be  able 
to  delegate  the  right  to  printOnePageHP  and  the 
delegation  will  only  be  valid  if  the  entity  she  delegates 
to  satisfy  all  the  associated  conditions  as  well. 
delegateSpeechAct(  tim,  jane,  right(jane, 

delegate(  right(X,  print,  group -member(X, 

Group))),  (employ  ee(jane,  ’UMBC’),  time- 

now(morning)))) 

4.1.  Delegation  Types 

We  identify  two  types  of  delegation,  while-delegations 
and  when-delegations.  A  while -delegation  forces  all 
following  delegators  to  satisfy  its  conditions  in  order  to  be 
true.  Whereas  a  when-delegation  requires  the  immediate 
delegator  to  satisfy  its  conditions  only  at  the  time  of 
the  delegation  and  not  after.  For  example,  consider  a 
when-delegation  giving  Jane  the  right  to  delegate  when 
she’s  an  employee.  All  the  delegations  that  Jane  made 
while  she  was  an  employee  hold  even  after  she  leaves.  On 
the  other  hand,  a  similar  while-delegation  will  fail  once  the 
delegator  leaves  the  company.  The  while  delegation  is  the 
default  delegation  type. 

Example  11.  The  following  represents  the  example  de¬ 
scribed  above 

•  When-Delegation 

delegateWhenSpeech(mark,  matthew,  right(Action, 
Condition ))  ,  Matthew  satisfies  Condition  — )► 
has( Matthew,  right(Action,  Condition) 

Matthew  no  longer  satisfies  Condition  — )► 

has( Matthew,  right(Action,  Condition) 

•  While-Delegation  or  Default  Delegation 

delegateSpeech(mark,  matthew,  right(Action,  Condi¬ 
tion )),  Matthew  satisfies  Condition  — has(Matthew, 
right(Action,  Condition) 


Matthew  does  not  satisfy  condition  — NOT 
has( Matthew,  right(Action,  Condition) 

5.  Policy  Engine 

We  have  developed  a  policy  engine  that  reasons  over 
policies  described  in  the  Rei  policy  language  and  uses  the 
policies,  meta-policies  and  domain  knowledge  to  make  se¬ 
curity  decisions  about  access  rights  and  obligations.  Along 
with  policies  in  Prolog,  the  policy  engine  also  accepts  poli¬ 
cies  in  RDF-S  that  are  based  on  the  existing  Rei  ontology. 
The  policy  engine  is  developed  in  Java  and  uses  Prolog  as  a 
reasoning  engine.  It  currently  has  a  commandline  interface 
and  a  Java  interface.  We  envision  that  the  policy  engine 
will  be  used  as  a  security  module  by  an  application  along 
the  similar  lines  as  our  application,  Vigil  -  a  security  frame¬ 
work  for  pervasive  environments. 

6.  Application  :  Pervasive  Environment 

In  the  ubiquitous  computing  paradigm,  information  and 
services  are  accessible  virtually  anywhere  and  at  any  time 
via  any  device  -  phones,  PDAs,  laptops  or  even  watches 
[22,  29] .  The  SmartSpace  scenario  is  the  first  step  towards 
realizing  this  vision.  Smart  homes  and  offices  consist  of  in¬ 
telligent  services  that  are  accessible  to  users  via  handheld 
devices  connected  over  short  range  wireless  links.  The  ser¬ 
vices  will  be  integrated  seamlessly  into  the  environment  that 
the  user  is  familiar  with,  enabling  easy  and  automatic  us¬ 
age.  This  is  the  vision  that  guides  our  research  on  the  Vigil 
system.  We  define  a  SmartSpace  as  a  dynamic  environ¬ 
ment  that  provides  an  infrastructure  for  providing  services 
to  mobile  users  via  some  short  range  wireless  communica¬ 
tion  link. 

We  have  designed  and  implemented  Vigil,  a  security 
framework,  which  provides  access  control  to  services  in 
SmartSpaces  [14,  26].  Within  a  confined  space,  the  client 
can  access  services  provided  by  the  nearest  Vigil  System  via 
some  short-range  wireless  technology.  Vigil  acts  as  an  ac¬ 
tive  proxy  by  executing  services  on  behalf  of  any  client  that 
requests  them.  This  minimizes  the  resource  consumption 
on  the  client  and  also  avoids  having  the  services  installed 
on  each  client  that  wishes  to  use  them,  which  is  a  blessing 
for  most  resource-poor  mobile  clients. 

Vigil  consists  of  five  functional  components:  (i)  Com¬ 
munication  Managers,  (ii)  Service  Managers,  (iii)  Certifi¬ 
cate  Managers,  (iv)  Security  Agents,  and  (v)  Clients.  Com¬ 
munication  Managers  handle  communication  between  var¬ 
ious  entities  in  the  system.  The  Communication  Manager 
is  flexible  and  allows  any  medium  to  be  used  for  commu¬ 
nication,  but  for  implementation  purposes,  we  have  used 
Infrared,  CDPD[25]  and  Bluetooth[l].  Users  and  services 


Figure  2.  Overview  of  the  Vigil  system.  There  are  several  SmartSpaces  in  an  organization.  In  every 
SmartSpace,  a  user  uses  the  Vigil  framework  to  gain  access  to  services  in  that  Space.  A  user  can 
also  request  permission  from  another  user  to  access  a  Service.  Though  Vigil  has  been  conceptually 
shown  as  a  central  system,  it  is  actually  made  up  of  distributed  components. 


are  treated  equally  as  Clients.  All  clients  communicate  via 
a  language  based  on  Extensible  Markup  Language(XML) 
[28].  All  communication  is  encrypted  via  Public  Key  In¬ 
frastructure  (PKI).  Vigil  does  not  assume  that  the  end  points 
are  computationally  robust  and  instead  relies  on  a  simplified 
PKI.  The  entities  in  the  Vigil  system  enjoy  non-repudiation, 
authentication,  and  protection  from  replay  attacks  vis-a-vis 
the  simplified  PKI.  The  Certificate  Manager  is  responsible 
for  generating  x.509  version  3  digital  certificates  for  each 
entity  in  the  Vigil  system  and  for  responding  to  certificate 
validation  queries  from  Service  Managers.  Service  Man¬ 
agers  are  responsible  for  client  and  service  management. 
The  Security  Agents  provide  access  control  for  Services. 
Finally,  users  and  services  are  treated  equally  as  Clients. 

Our  infrastructure  is  designed  to  minimize  the  load  on 
portable  devices  and  provide  a  media  independent  infras¬ 
tructure  and  communication  protocol  for  the  provision  of 
services.  Vigil,  in  addition  to  solving  the  issue  of  control¬ 
ling  access  to  services  in  a  SmartSpace ,  also  accommodates 
users  that  are  foreign  entities,  that  is  entities  that  are  not 
known  to  the  system  in  advance.  In  many  conventional  sys¬ 
tems,  access  rights  are  static;  agents  are  not  able  to  request 
permission  to  access  a  Service  to  which  they  are  not  pre¬ 
authorized.  The  Vigil  architecture  allows  agents  to  ask  for 
permission  and  other  agents  to  actually  delegate  rights  that 
they  have.  This  extends  the  security  policy  in  a  secure  man¬ 
ner,  as  only  agents  that  have  the  permission  to  delegate,  can 
actually  delegate. 

A  pervasive  system  is  divided  into  SmartSpaces ,  and 


each  SmartSpace  in  controlled  by  a  Service  Manager.  The 
Service  Manager  acts  as  broker,  matching  client  requests 
to  registered  services.  A  Service  Manager  uses  one  or 
more  Security  Agents  to  maintain  security.  The  Security 
Agent  enforces  the  security  policy  of  the  organization  or 
SmartSpace  and  interprets  the  policy  to  provide  controlled 
access  to  Services.  There  is  a  global  policy  associated 
with  the  organization  and  a  local  policy  associated  with  a 
SmartSpace.  All  security  agents  in  the  organization  will  en¬ 
force  the  global  policy  and  will  additionally  enforce  a  local 
policy,  which  is  specific  to  the  Space.  Vigil  uses  a  sub¬ 
set  of  the  Rei  constructs  to  specify  policies  which  include 
rules  for  role  assignment,  access  control  (rights  and  pro¬ 
hibitions),  delegation  and  revocation.  The  Security  Agent 
stores  Rei  policies,  meta-policies  and  contextual  informa¬ 
tion  in  a  knowledge  base  and  makes  security  decisions  by 
reasoning  over  this  information. 

Figure  2  illustrates  the  working  of  the  Vigil  system.  A 
Service  Manager  on  receiving  a  request  for  a  service  asks 
the  Security  Agent  whether  the  request  is  valid.  The  Secu¬ 
rity  Agent  replies  with  a  positive  or  negative  response  de¬ 
pending  on  the  security  policy.  Based  on  this  response,  the 
Service  Manager  allows  or  denies  the  clients  request. 

When  a  user  needs  to  access  a  service  that  it  does  not 
have  the  right  to  access,  it  requests  another  user,  who  has 
the  right  for  the  permission  to  access  the  Service.  If  the  en¬ 
tity  requested  has  the  permission  to  delegate  the  access  to 
the  Service,  the  entity  sends  a  delegation  message  to  the  Se¬ 
curity  Agent  and  the  requester.  The  Security  Agent  checks 


the  roles  of  the  delegator  and  the  delegatee  and  ensures  that 
the  delegator  has  the  right  to  delegate,  and  that  the  delega¬ 
tion  follows  the  security  policy.  It  then  adds  the  permission 
for  the  Client  to  access  the  Service,  but  sets  a  very  short  pe¬ 
riod  of  validity  for  the  permission.  Once  this  period  is  over, 
The  Security  Agent  has  to  reprocess  the  delegation.  This 
is  very  useful  incase  of  revoked  certificates,  delegations  or 
rights.  If  any  one  entity  in  the  delegation  chain  loses  the  per¬ 
mission,  then  it  is  propagated  down  the  chain  very  quickly, 
till  everyone  in  the  chain  after  the  entity  loses  the  ability. 

7.  Background 

According  to  Sloman,  policies  define  a  relationship  be¬ 
tween  subjects  and  targets  [23].  Policy  domains  are  groups 
on  which  the  policy  applies.  Policies  affect  behavior  of  ob¬ 
jects  in  domains.  Sloman  believes  that  it  is  important  to  rep¬ 
resent  and  interpret  policy  information.  He  classifies  poli¬ 
cies  into  authorization  and  obligation  and  states  that  there 
are  two  kinds  of  constraints  on  policies;  temporal,  and  pa¬ 
rameter  value.  In  contrast,  Rei  handles  authorizations,  pro¬ 
hibitions,  obligations  and  dispensation  policy  rules  and  al¬ 
lows  policies  to  be  split  into  actions,  constraints  and  policy 
objects.  Rei  also  allows  constraints  to  be  domain  dependent 
and  external  to  the  policy  specifications. 

Ponder  [5]  allows  general  security  policies  to  be  speci¬ 
fied.  The  authors  of  Ponder  define  a  policy  as  a  set  of  rules 
that  defines  a  choice  in  the  behavior  of  a  system.  Ponder  is 
a  declarative,  object  oriented  language  for  specifying  secu¬ 
rity  and  management  policies.  It  allows  policy  types  to  be 
defined  to  which  any  policy  element  can  be  passed  to  create 
a  specific  instance.  This  seems  to  be  a  useful  ability  and, 
in  fact,  Rei  allows  this  to  be  done  automatically.  Rei  al¬ 
lows  types  of  policy  objects  to  be  defined  and  allows  them 
to  be  linked  dynamically  to  subjects.  Ponder  allows  defini¬ 
tion  of  positive  and  negative  authorization  policies  (access 
control),  information  filtering  (transforming  requested  in¬ 
formation  into  a  suitable  format),  delegation  positive  and 
negative.  Ponder  includes  a  very  simple  notion  of  dele¬ 
gation,  which  we  believe  is  very  important  in  distributed 
systems.  Rei  supports  different  kinds  of  delegation  and  in¬ 
cludes  mechanisms  to  control  delegation  propagation.  Pon¬ 
der  describes  meta  policies  as  policies  about  policies,  which 
is  similar  to  the  way  Rei  views  them.  Ponder  provides  a 
Group  construct  for  group  related  policies  and  a  Role  con¬ 
struct  for  role  policies.  However,  Rei  does  not  distinguish 
between  role  based,  group  based  and  individual  policies,  al¬ 
lowing  them  to  be  described  using  the  same  set  of  constructs 
leading  to  simpler  policies  and  more  uniformity. 

Lupu  classifies  conflicts  into  modality  conflicts  and  ap¬ 
plication  specific  conflicts  [16].  Modality  conflicts  arise 
when  two  or  more  policies  with  opposite  modalities  refer 
to  the  same  subjects.  Application  specific  conflicts  refers 


to  the  consistency  of  what  is  contained  in  the  policy  and 
external  criteria,  e.g.,  the  same  manager  cannot  authorize 
payments  and  sign  the  payment  checks.  Lupu  suggests  a 
couple  of  ways  of  resolving  modality  conflicts;  deciding  a 
default  priority,  assigning  explicit  priorities  to  rules,  finding 
the  distance  between  the  policy  and  the  managed  object  to 
name  a  few.  Rei  accepts  Lupu’s  definition  of  modality  con¬ 
flicts  but  does  not  use  the  suggested  mechanisms.  Rei  pro¬ 
vides  a  construct  for  specifying  the  modality  which  holds 
precedence  for  sets  of  agents  and  actions  grouped  by  cer¬ 
tain  conditions.  Rei  also  allows  priorities  to  be  assigned  to 
policy  rules  and  policies. 

Most  policy  languages  provide  a  certain  set  of  constructs 
in  some  sort  of  a  programming  language.  However,  there 
has  been  some  work  in  representing  policies  in  logic  [9,  30]. 
Woo  and  Lam  [30]  propose  the  use  of  default  logic  for  au¬ 
thorization  policies.  Their  access  control  decisions  are  not 
always  conclusive  and  the  work  does  not  include  conflict 
resolution  mechanisms.  Jajodia  et  al.  describe  the  specifi¬ 
cations  of  a  language  based  on  stratified  logic  that  tries  to 
support  different  access  control  policies  [9] .  Their  Autho¬ 
rization  Specification  Language  (ASL)  allows  users  to  not 
only  specify  authorization  policies,  but  also  specify  the  way 
the  decisions  over  these  policies  are  made.  The  language 
supports  objects,  on  which  actions  are  carried  out,  and  sub¬ 
jects,  which  can  be  users,  groups  and  roles.  ASL  depends 
heavily  on  the  authors’  understanding  and  interpretation  of 
groups  and  roles,  whereas  in  Rei,  these  concepts  belong  en¬ 
tirely  to  the  domain  in  which  it  is  being  used,  and  can  be 
interpreted  as  required  by  the  domain.  ASL  defines  an  au¬ 
thorization  policy  as  a  4-tuple  consisting  of  an  object,  user, 
role  set  and  an  action.  This  language,  though  a  step  in  the 
right  direction,  is  complicated  because  it  consists  of  a  large 
set  of  interdependent  rules  that  the  user  has  to  fully  under¬ 
stand  in  order  to  use,  and  is  not  as  expressive  as  Rei.  ASL 
does  not  make  provisions  for  domain  dependent  informa¬ 
tion  and  insists  on  only  a  specific  set  of  conditions.  Rei  can 
be  used  to  specify  role  based,  group  based  and  individual 
policies  with  the  same  constructs  using  certain  user  defined 
conditions.  ASL  does  include  conflict  resolution  but  ex¬ 
pects  a  set  of  rules  (in  terms  of  its  predicates)  to  be  defined 
for  every  access.  Conflict  resolution  is  more  straightforward 
in  Rei  through  its  two  mechanisms  of  modality  precedence 
and  priority  specification.  For  example,  in  Rei  it  is  possi¬ 
ble  to  state  that  for  all  possible  actions  on  colors  printers 
in  a  certain  lab,  permissions  should  hold  precedence  over 
prohibitions. 

8.  Contributions 

Rei  is  a  flexible  and  expressive  policy  language  that  is 
based  on  deontic  concepts  and  which  can  be  used  to  de¬ 
scribe  several  kinds  of  policies.  For  example,  consider  se- 


curity  policies.  Security  policies  restrict  access  to  certain 
resources  in  an  organization.  Rei  can  be  used  to  create  ac¬ 
tions  on  the  resources  and  to  describe  role  based  rights  and 
prohibitions  for  the  users  in  the  organization.  On  the  other 
hand,  management  policies  define  the  role  of  an  individ¬ 
ual  in  terms  of  his  duties  and  rights,  which  map  directly 
into  obligations  and  rights  in  Rei.  Conversation  policies  are 
very  important  in  semi  autonomous  environments  [21]  like 
pervasive  environments.  The  order  in  which  speech  acts 
occur  is  called  a  conversation.  By  specifying  what  speech 
acts  an  agent  can  use  under  certain  conditions  (rights),  and 
by  specifying  what  speech  acts  an  agent  should  use  (obliga¬ 
tion)  under  certain  conditions  (could  include  the  speech  acts 
just  received),  a  policy  for  conversations  can  be  specified  in 
Rei.  Other  policies  can  similarly  be  described  in  terms  of 
deontic  principles  making  Rei  versatile. 

A  specification  is  correct  if  it  is  both  consistent  and  com¬ 
plete  [9].  Though  Rei  allows  inconsistent  or  incomplete 
specifications  to  be  described,  its  policy  engine  is  correct. 
Rei’s  policy  engine  is  consistent  because  every  request  is 
either  allowed  or  denied  but  not  both.  This  is  due  to  the 
structure  of  the  meta  policies,  which  resolves  conflicts  forc¬ 
ing  the  engine  to  come  to  either  a  positive  or  negative  deci¬ 
sion.  The  policy  engine  is  complete  because  every  request 
has  a  result. 

Rei  is  composed  of  domain  dependent  information  and 
domain  independent  information.  Rei  allows  policy  mak¬ 
ers  to  use  application  specific  information  that  Rei  has  no 
prior  knowledge  of  but  can  still  reason  over  while  making 
decisions. 

Rei  allows  types  of  policy  objects  to  be  specified.  For  ex¬ 
ample,  all  the  rights  on  a  certain  resource,  prohibition  from 
printing  to  any  color  printers  on  the  fifth  floor,  and  the  right 
to  delete  all  the  files  belonging  to  your  colleague. 

As  mentioned  earlier,  the  same  structures  of  Rei  allow 
individual  policies  as  well  as  group  and  role  based  policies 
to  be  specified  making  it  uniform. 

The  languages  in  our  bibliography  did  not  take  delega¬ 
tion  into  consideration.  However,  we  believe  that  it  is  re¬ 
quired  in  distributed,  dynamic  systems  and  should  be  in¬ 
cluded  in  the  policy  specifications.  Rei’s  policy  engine 
includes  strong  delegation  management  making  it  useful 
for  dynamic  systems,  consisting  of  transient  resources  and 
users,  and  distributed  systems,  in  which  creating  compre¬ 
hensive  policies  may  be  time  consuming.  Rei  includes  two 
kinds  of  delegation  and  provides  a  standard  way  of  control¬ 
ling  and  propagating  access  rights  through  delegation. 

9.  Future  Work  and  Conclusion 

In  this  paper  we  described  the  specifications  of  our  pol¬ 
icy  language,  Rei,  that  we  designed  and  developed  for  dis¬ 
tributed,  dynamic  environments  like  pervasive  systems.  Rei 


is  based  on  deontic  concepts  which  allows  policies  of  dif¬ 
ferent  types  to  be  specified  in  terms  of  rights,  obligations, 
dispensations,  and  prohibitions.  We  are  currently  working 
on  identifying  a  deontic  logic  that  Rei  is  most  closely  re¬ 
lated  to. 

Our  policy  engine  is  under  development  and  currently 
supports  almost  all  the  expressivity  provided  by  the  policy 
language.  The  engine  supports  action  operators  for  Rights 
and  the  support  for  the  other  policy  objects  is  currently  un¬ 
der  development.  However,  it  currently  does  not  handle  all 
the  nesting  capable  by  speech  acts  like  requesting  a  dispen¬ 
sation.  The  policy  language  accepts  RDFS  representations 
of  entities  and  properties  based  on  the  Rei  ontology  but  as 
mentioned  earlier  we  are  working  on  representing  condi¬ 
tions  in  semantic  languages.  Though  conflicts  are  detected 
and  resolved  at  run-time,  we  believe  pre-determining  policy 
conflicts  also  has  several  practical  uses.  We  are  investigat¬ 
ing  a  feasible  solution  for  statically  detecting  conflicts  in 
Rei  policies.  Our  future  work  will  also  include  developing 
DAML+OIL  and/or  OWL  ontologies. 
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